Object-oriented framework for generic adaptive control

ABSTRACT

A system and method are described for constructing and implementing generic software agents for automated tuning of computer systems and applications. The framework defines the modules and interfaces to allow agents to be created in a modular fashion. The specifics of the target system are captured by adaptors that provide a uniform interface to the target system. Data in the agent is managed by a metric manager, and controller modules implement the desired control algorithms. The modular structure and common interfaces allow for the construction of generic agents that are applicable to a wide variety of target systems, and can use a wide variety of control algorithms.

CROSS-REFERENCE TO RELATED APPLICATION

This application is a Continuation of U.S. patent application Ser. No.10/059,665, filed on Jan. 29, 2002, which is fully incorporated hereinby reference.

BACKGROUND OF THE INVENTION

1. Technical Field

The present invention relates generally to the performance of computersystems and, in particular, to a system and method for automatedperformance tuning of computer systems and applications in a generic,application-independent manner.

2. Description of Related Art

There has been a tremendous growth in the complexity of distributed andnetworked systems in the past few years. In large part, this can beattributed to the exploitation of client-server architectures and otherparadigms of distributed computing. Such computer systems and software(operating systems, middle ware and applications) have become so complexthat it is difficult to configure them for optimal performance.

Complex applications such as databases (e.g., ORACLE, DB2), messagequeuing systems (e.g., MQSERIES) and application servers (e.g.,WEBSPHERE, DOMINO) have literally tens and hundreds of parameters thatcontrol their configuration, behavior and performance (DOMINO/DB2 adminguide). The behavior of such a complex system is also governed by thedynamic loads that are placed on the system by the system users. Ittakes considerable expertise to set individual parameters, and it iseven more challenging to understand the interaction between parametersand the resultant effect on the behavior and performance of the system.Another factor that increases the difficulty of administering thesesystems is that such systems can be very dynamic and therefore mayrequire constant monitoring and adjustment of their parameters, forinstance if the workloads change over time.

Thus, the total cost of ownership (TCO) of the particular system mayincrease not only due to the cost of hiring expert help, but also due topotentially lost revenue if the system is not configured properly. Toreduce the TCO and the burden on system administrators, many softwarevendors are now turning to software agents to help manage the complexityof administering these complex systems.

Software agents are very well suited to the task of controlling suchsystems. Prior expert knowledge could be incorporated once and for allin the agent, thereby reducing the need for expertise by the end-user.In addition, the software agent can be more closely tied to the systemand can perform even closer monitoring and updating than humanlypossible. Recent advances in the fields of Control Theory, Optimization,Operations Research and Artificial Intelligence provide a wealth ofalgorithms and techniques to dynamically tune the behavior of complexsystems, even in the absence of much expert knowledge.

A variety of target-specific or “customized automated tuning systems”(CATS) have been developed. Examples include systems by: (1) Abdelzaheret al., as described in “End-host Architecture for QoS-AdaptiveCommunication,” IEEE Real-time Technology and Applications Symposium,Denver, Colo., June 1998, the disclosure of which is incorporated byreference herein; and (2) Aman et al., as described in “Adaptivealgorithms for managing a distributed data processing workload,” IBMSystems Journal, Vol. 36, No 2, 1997, the disclosure of which isincorporated by reference herein. The system of Abdelzaher et al.controls quality of service for the delivery of multimedia using taskpriorities in a communications subsystem. The system of Aman et al.provides a means by which administrators specify response time andthroughput goals to achieve in MVS (Multiple Virtual Storage) systemsusing MVS-specific mechanisms to achieve these goals.

The concept of “tuning” seeks to improve service levels by adjustingexisting resource allocations. To accomplish the preceding requiresaccess to metrics and to the controls that determine resourceallocations. In general, there are three classes of metrics, as follows:(1) “configuration metrics” that describe performance related featuresof the target that are not changed by adjusting tuning controls, suchas, for example, line speeds, processor speeds, and memory sizes; (2)“workload metrics” that characterize the load on the target, such as,for example, arrival rates and service times; and (3) “service levelmetrics” that characterize the performance delivered, such as, forexample, response times, queue lengths, and throughputs.

“Tuning controls” are parameters that adjust target resource allocationsand hence change the target's performance characteristics. We give a fewexamples. LOTUS NOTES, an e-mail system and application framework, has alarge set of controls. Among these are: NSF_BufferPoolSize for managingmemory, Server_MaxSessions for controlling admission to the server, andServer_SessionTimeout for regulating the number of idle users. InWeb-based applications that support differentiated services, there aretuning controls that determine routing fractions by service class andserver type. MQ SERIES, a reliable transport mechanism in distributedsystems, has controls for storage allocations and assigning priorities.Database products (e.g., IBM's DB/2) expose controls for sort indicesand allocating buffer pool sizes.

CATS require that metrics and tuning controls be identified in advanceso that mechanisms for their interpretation and adjustment can beincorporated into the automated tuning system. Thus, CATS constructionand maintenance still require considerable expertise. With the advent ofthe Internet, software systems and their components evolve rapidly, asdo the workloads that they process. Thus, it may well be that automatedtuning systems must be updated on a rate approaching that at whichtuning occurs. Under such circumstances, the value of automated tuningis severely diminished.

The prior art related to automated tuning has mostly focused ondeveloping specific algorithms and architectures that are very tightlycoupled to the target system (i.e., the system being controlled). Insuch cases, the algorithms cannot be easily reapplied to other systems,nor can other control schemes be inserted into the proposedarchitecture.

Existing prior art for target-independent automated tuning does notconsider architectural support for access to the metrics and controls.Realizing generic, automated tuning requires well defined interfaces sothat a generic automated tuning system can access the data required fromthe target. Previous work has ignored these considerations. The searchfor appropriate settings of tuning controls is facilitated by exposinginformation about the semantics of metrics and the operation of tuningcontrols. In particular, it is helpful for the target to place metricsinto the categories of configuration, workload, and service level. Thesedesignations can aid the construction of a generic system model.Further, there should be a way to express the directional effects oftuning control adjustments since having such knowledge reduces thecomplexity of the search for appropriate settings of tuning controls.Past work has not focused on these concerns.

SUMMARY OF THE INVENTION

The problems stated above, as well as other related problems of theprior art, are solved by the present invention, an object-orientedframework for generic adaptive control. The present invention may beapplied to one or more target systems, such as, for example, one or morecomputer systems in a network.

Advantageously, the present invention provides a flexible softwarearchitecture for the creation of generic automated tuning agents (GATA),which are software agents that are made of one or more controllermodules (also referred to herein as “Autotune Controllers”), and one ormore target system (application) adaptors (also referred to herein as“Autotune Adaptors”). Moreover, the invention allows a user to specifythe interfaces between the agent's components (controllers and adaptors)so that other components can be substituted in a plug-and-play manner.Also, the present invention provides interfaces that allow thecontrollers to be interconnected in an arbitrarily complex manner,allowing for the implementation (and composition) of any computablecontrol strategy. Further, the present invention provides a mechanism toallow agents created in the framework to be interconnected and tocommunicate with each other to form a potentially complex network and/orhierarchy of software agents. Additionally, the present inventionprovides customizer interfaces that allow optional and flexible manualmonitoring and intervention where necessary.

This architecture allows the implementation of many control strategiesin the generic framework. Moreover, it allows the control strategy to beimplemented in a modular fashion so that it is not necessarily tied tothe target system. The modularity further allows the same controlstrategy to be easily applied to different target systems. Thearchitecture is flexible enough to implement strategies requiringmultiple controllers. In addition, it enables inter-agent communicationthat leverages the existing infrastructure (without requiring additionalcoding). This allows us to construct complex agent networks forcontrolling complex, distributed systems.

According to an aspect of the present invention, there is provided atuning system for automatically tuning one or more target systems. Ametric manager manages at least one set of metrics corresponding to theone or more target systems. One or more controllers implement one ormore control strategies based upon the at least one set of metrics. Theone or more control strategies are independent of a particulararchitecture of any of the one or more target systems. One or moreadaptors interface with the one or more target systems with respect tothe one or more control strategies. At least one of the one or moreadaptors is specific to a corresponding one of the one or more targetsystems.

According to another aspect of the present invention, the tuning systemfurther comprises at least one customizer for receiving user inputs forcustomizing at least one of the metric manager, the one or morecontrollers, and the one or more adaptors. The at least one customizeris a graphical user interface.

According to yet another aspect of the present invention, the one ormore controllers comprise a master controller for resolving conflictsbetween the one or more control strategies.

-   1. According to still another aspect of the present invention, the    tuning system has a capability of invoking other tuning systems to    form a hierarchical tuning system with respect to the one or more    target systems.-   2. According to a further aspect of the present invention, the    tuning system and the other tuning systems operate cooperatively to    implement the one or more control strategies.-   3. According to a yet further aspect of the present invention, at    least some of the one or more controllers are modular and have a    capability of being deleted from the tuning system, modified, or    replaced.-   4. According to a still further aspect of the present invention, at    least some of the one or more adaptors are modular and have a    capability of being deleted from the tuning system, modified, or    replaced.    These and other aspects, features and advantages of the present    invention will become apparent from the following detailed    description of preferred embodiments, which is to be read in    connection with the accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram depicting a typical operating environment towhich a software agent according to the present invention may beapplied, according to an illustrative embodiment of the presentinvention;

FIG. 2 is a block diagram illustrating the components comprising asoftware agent and interconnections corresponding thereto, according toan illustrative embodiment of the present invention;

FIG. 3 is a tree illustrating a Metrics type hierarchy, according to anillustrative embodiment of the present invention;

FIG. 4 is a block diagram illustrating a simple agent for controlling asingle application using a single control method, according to anillustrative embodiment of the present invention;

FIG. 5 is a block diagram illustrating how multiple control strategiescan be included in a single agent, according to an illustrativeembodiment of the present invention;

FIG. 6 is a block diagram depicting a hierarchical controlconfiguration, according to an illustrative embodiment of the presentinvention;

FIG. 7 is a block diagram of an agent that is part of the hierarchicalcontrol configuration of FIG. 6, according to an illustrative embodimentof the present invention; and

FIG. 8 is a flow diagram illustrating a method for creating an Autotunesoftware agent, according to an illustrative embodiment of the presentinvention.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

FIG. 1 is a block diagram depicting a typical operating environment towhich a software agent according to the present invention may beapplied, according to an illustrative embodiment of the presentinvention. The agent 110 receives information from a human (or software)administrator entity 120 in terms of the desired service-levelrequirements, as well as various parameters affecting the controller'soperation. Other inputs to the agent 110 are received from the targetapplication 130 itself, in terms of the configuration, workload andservice level metrics, as discussed herein above. Using these inputs,the agent 110 computes the control settings for the target system orsystems 130. These control settings are then passed on to the targetsystem 130. Thus, we see that the agent 110 operates in a closed loopwith respect to the target system 130. FIG. 1 also shows that thebehavior of the target system 130 is governed by the workload imposed onit by the users 140. A final aspect of FIG. 1 is that the administrator120, in addition to providing the controller parameters, has access tometrics related to the controller's operation. This can be used tomonitor the automated agent 110, to ensure that it is behaving properlyand to measure the efficiency of its operation.

The internal components of such an agent are outlined in FIG. 2. Inparticular, FIG. 2 is a block diagram illustrating the componentscomprising a software agent and interconnections corresponding thereto,according to an illustrative embodiment of the present invention. Wecall this agent architecture an Autotune Agent.

The software agent of FIG. 2 includes: a master Autotune Controller 210;one or more slave Autotune Controllers (hereinafter “slave AutotuneController”) 220; one or more Autotune Adaptors (hereinafter “AutotuneAdaptor”) 230; a repository 250; a metric manager 240; an administratorapplication programming interface (API) 265; customizers 270, 280, and290. The software agent of FIG. 2 interacts with one or more targetsystems and/or one or more other Autotune Agents (hereinafterinterchangeably referred to as “target system” or “other Autotune Agent”to illustrate that a software agent according to the present inventionmay interact with other agents as well as target systems which are notother agents) 260. The preceding illustrates that an Autotune agent canitself be a target system of another Autotune agent.

An Autotune Agent can be composed of one or more Autotune Controllersand one or more Autotune Adaptors. When there are multiple AutotuneControllers in the agent, one of them is designated the MasterController 210 and is responsible for generating the final controlaction. Depending on the control algorithm, the Master Controller 210may use any of the other (Slave) Controllers 220 as subroutines to helpdetermine the desired control action.

FIG. 3 is a tree illustrating the type hierarchy of Metrics, accordingto an illustrative embodiment of the present invention. Metrics 390 aredivided into read-only 370 and read/write metrics 380. In theillustrative embodiment of the present invention described herein,configuration 310, workload 320 and service level 330 metrics areread-only, whereas the Tuning Control 340 metrics are consideredread/write metrics. Of course, other arrangements may be employed, whilemaintaining the spirit and scope of the present invention

Metrics are managed through the Metric Manager 240. This entity providesinterfaces to add, delete and list (getMetric( ) in FIG. 2) the set ofMetrics known to the agent. The Metric Manager 240 allows theAdministrator, via the customizer 280 or the Administrator API 265, toselect a subset of the known metrics to be logged to the repository 250,which can be used for logging purposes. The Metric Manager 240 providesa set of miscellaneous functions such as selecting the loggingdestination and enabling/disabling the logging function.

The Autotune Adaptor 230 is the interface of the Agent to the targetapplication(s) 260. Each Autotune Adaptor 230 defines the set of Metricsthat it knows about. This set can be obtained by querying the AutotuneAdaptor 230 (getMetrics( ) in FIG. 2). For the read-only metrics, theAutotune Adaptor 230 provides a means of getting the latest value ofthose metrics from the target system 260 (process( ) in FIG. 2). For theTuning Control metrics, the Autotune Adaptor 230 provides a means to setthe value of that tuning control on the target system 260 (setControl( )in FIG. 2). The Autotune Adaptor 230 is target-specific, and provides anabstraction so that the control algorithm itself need not be directlytied to a particular target system. In order to apply the same controlalgorithm to another target system, one need only substitute an AutotuneAdaptor for that target system. Note that the target system 260 can beany external entity including, for example, another Autotune Agent. Thisproperty allows us to build a chain of agents, which we will utilizelater to build an agent hierarchy.

An Autotune Controller 210, 220 implements a control strategy. TheAutotune Controller 210, 220 obtains all metrics of interest from theMetric Manager (using getMetric( )). The Autotune Controller 210, 220provides mechanisms to compute errors (deviations from the desiredservice level), compute new control values and to set those controlvalues (by invoking the corresponding Autotune Adaptor 230 component viasetControl( )).

A typical control loop is as follows:

-   1. If (synchronous mode), then:-   a. Invoke synchronous adaptors-   2. Compute errors from desired service level-   3. Compute new control value (this implements control algorithm)-   4. If (current controller is the Master Autotune Controller 210),    then:-   a. set the control value-   5. Repeat

It is to be appreciated that step 2 immediately above (compute errors)is an optional step. While most control algorithms operate on the error,there are some that do not operate on the error. Of course, othervariations are possible and readily contemplated by one of ordinaryskill in the related art.

The Autotune Adaptors 230 may operate in a synchronous or asynchronousmanner. “Synchronous” means that the Autotune Adaptor 230 is invokedjust prior to computing the new control value. In asynchronous mode, theAutotune Adaptor 230 is assumed to be invoked on its own at some other(user-defined) frequency to obtain the latest Metric values. Thisfeature allows us to implement Autotune controllers where the controlfrequency is not the same as the sensing frequency.

In computing errors from the desired service level, the Autotunecontroller may access any of the Metrics known to the Metric Manager240, as necessary.

The user-interface for each of the components (Metric Manager 240,Autotune Adaptor 230, Autotune Controllers 210, 220) is provided throughCustomizers 270, 280, 290. Customizers are entities that provide a GUIto the low-level details of each component. In the illustrativeembodiments described herein, there is one Customizer for each elementthat is part of an agent. Of course, other arrangements are possible,including, but not limited to one Customizer for each type of element(e.g., Autotune controller, adaptor, and so forth) that is part of anagent. In the case of the Metric Manager 240, for example, Customizersallow a user to specify which metrics are to be logged, the location ofthe log file, and so forth. In the case of an Autotune Controller, theyallow us to set the control frequency, select the Master AutotuneController, etc. For the Autotune Adaptor 230, we may choose theoperation mode: synchronous/asynchronous and also set the tuning controlmanually (in case we do not want the automated agent to operate). TheCustomizers 270, 280, 290 also provide a way to expose the availableMetrics to the user, so that real-time monitoring may be performed.

We now provide concrete examples of how this framework can be used toeasily create software agents for controlling a wide variety of computersystems. In order to instantiate a particular agent, one needs thefollowing components: Autotune Adaptors for each target system, and one(or more) control algorithms.

FIG. 4 is a block diagram illustrating a simple agent for controlling asingle application using a single control method, according to anillustrative embodiment of the present invention. The software agent ofFIG. 4 includes: a single Autotune Controller 410; an Autotune Adaptor460; a repository 450; a metric manager 440; an administrator API 465;customizers 470, 480, and 490. The software agent of FIG. 4 interactswith a target systems or other Autotune Agents (hereinafterinterchangeably referred to as “target system” or “other AutotuneAgent”) 460.

The basic agent creation process for a scenario with a single targetsystem and a single control algorithm (as in FIG. 4) is shown withrespect to FIG. 8 below.

The same Agent, using the same control strategy can be targeted to adifferent system simply by replacing the current Adaptor component withthat for the new target system. This enables reuse of existingknowledge. Similarly, the control algorithm can be easily changed byreplacing the Controller module.

FIG. 5 is a block diagram illustrating how multiple control strategiescan be included in a single agent, according to an illustrativeembodiment of the present invention.

The software agent of FIG. 5 includes: a master Autotune Controller 510;one or more slave Autotune Controllers (hereinafter “slave AutotuneController”) 520; an Autotune Adaptor 560; a repository 550; a metricmanager 540; an administrator API 565; customizers 570, 280, and 290.The software agent of FIG. 5 interacts with a target system or anotherAutotune Agent (hereinafter interchangeably referred to as “targetsystem” or “other Autotune Agent”) 560.

Here, the master Autotune Controller 510 implements the top-levelcontrol strategy that utilizes multiple lower-level control strategiesto compute the control value. This agent can be created as describedwith respect to FIG. 8 below.

FIG. 6 is a block diagram depicting a hierarchical controlconfiguration, according to an illustrative embodiment of the presentinvention. Here, the “US Autotune agent” 610 in turn invokes the “Eastcoast” 620 and “West coast” 630 Autotune agents, and these in turninvoke their subordinates 640, 650, 660, 670. The subordinates 640, 650,660, and 670 respectively control/manage app 1 681, app 2 682, app 3683, and app 4 684. This hierarchy can be implemented by a controller ateach level of the hierarchy.

FIG. 7 is a block diagram of an agent that is part of the hierarchicalcontrol configuration of FIG. 6, according to an illustrative embodimentof the present invention. In particular, a controller (a master Autotunehierarchical controller 710) at an internal node of the hierarchy isdepicted in FIG. 7. In the embodiment, it is interesting to note thatfor the higher-level agents, the target system is one of the lower-levelagents! This recursion is made possible by an Autotune Agent Adaptor 730that provides the standard Adaptor interface to another Autotune Agent760. This example illustrates the full generality of our framework, andillustrates that we can easily build complex chains of agents andcontrollers using the same framework. In addition to the master Autotunehierarchical controller 710, the Autotune Agent Adaptor 730, and theanother Autotune Agent 760, the embodiment of FIG. 7 further includes:one or more slave Autotune Controllers (hereinafter “slave AutotuneController”) 720; a repository 750; a metric manager 740; anadministrator API 765; customizers 770, 780, and 790.

FIG. 8 is a flow diagram illustrating a method for creating an Autotuneagent, according to an illustrative embodiment of the present invention.It is to be appreciated that some of the steps of the method of FIG. 8state “specify/create” with respect to certain elements of the Autotuneagent. This allows a user to either create the element or use acurrently existing element, depending on the needs of the user and thetuning to be performed on the target system.

One or more Autotune Adaptors are specified/created (step 820). It isthen determined whether the agent is to employ more than one controlstrategy or control algorithm (step 830). If so, then 1 through N (N>2)Autotune Controllers are specified/created (step 840), and the methodproceeds to step 860. Otherwise, a single Autotune controller isspecified/created (step 850), and the method proceeds to step 870.

At steps 860 and 870, control parameters are selected/generated via oneor more customizers. Both of steps 860 and 870 may include selectingparameters such as, for example, a controller frequency,synchronous/asynchronous mode, logging metrics, and so forth. However,step 860 must include selecting a master Autotune Controller from amongthe 1 through N Autotune controllers.

It is to be appreciated that the present invention provides a generic,automated tuning system. Advantageously, the present invention does notrequire experts to incorporate detailed knowledge of a target systeminto the tuning system. rather, the present invention may learn thetarget's performance characteristics. This may include having a genericautomated tuning system according to the present invention exploit priorknowledge of the target system, when such knowledge is available,reliable, and durable.

Although the illustrative embodiments have been described herein withreference to the accompanying drawings, it is to be understood that thepresent system and method is not limited to those precise embodiments,and that various other changes and modifications may be affected thereinby one skilled in the art without departing from the scope or spirit ofthe invention. All such changes and modifications are intended to beincluded within the scope of the invention as defined by the appendedclaims.

1. A computer-based tuning system for automatically tuning one or moretarget systems, comprising: a metric manager for managing at least oneset of metrics corresponding to the one or more target systems; one ormore controllers for implementing one or more control strategies foradaptively tuning performance characteristics of the one or more targetsystems based upon the at least one set of metrics, wherein the one ormore control strategies are independent of a particular architecture ofany of the one or more target systems, and one or more adaptorsproviding an abstract interface to the one or more target systems withrespect to the one or more control strategies, wherein at least one ofthe one or more adaptors is specific to a corresponding one of the oneor more target systems, wherein the one or more controllers invoke theone or more adaptors (i) to obtain metric values from the one or moretarget systems to compute tuning control values, and (ii) to tune theone or more target systems using the computed tuning control values. 2.The tuning system of claim 1, wherein each of the one or more controlstrategies corresponds to a separate computer program.
 3. The tuningsystem of claim 1, wherein said one or more controllers comprise amaster controller for resolving conflicts between the one or morecontrol strategies.
 4. The tuning system of claim 1, wherein the set ofmetrics comprise read-only metrics and read/write metrics.
 5. The tuningsystem of claim 4, wherein said one or more adaptors directly obtainlatest values of the read-only metrics from the one or more targetsystems.
 6. The tuning system of claim 4, wherein said one or moreadaptors set values corresponding to the read/write metrics on the oneor more target systems.
 7. The tuning system of claim 1, wherein saidmetric manager has a capability of adding, deleting, and listing the atleast one set of metrics.
 8. The tuning system of claim 1, wherein thetuning system has a capability of invoking other tuning systems to forma hierarchical tuning system with respect to the one or more targetsystems.
 9. The tuning system of claim 8, wherein the tuning system andthe other tuning systems operate cooperatively to implement the one ormore control strategies.
 10. The tuning system of claim 1, furthercomprising an administrator application programming interface (API) forspecifying service-level requirements of the one or more target systems.11. The tuning system of claim 1, further comprising an administratorapplication programming interface (API) for monitoring an operation ofthe tuning system.
 12. The tuning system of claim 1, wherein said metricmanager is capable of receiving an input specifying at least a subset ofmetrics to be stored from among the at least one set of metrics.
 13. Thetuning system of claim 1, wherein more than one of the one or morecontrollers is employed in a given application of the tuning system to agiven one of the one or more target systems.
 14. The tuning system ofclaim 1, wherein at least some of the one or more controllers aremodular and have a capability of being deleted from the tuning system,modified, or replaced.
 15. The tuning system of claim 1, wherein atleast some of the one or more adaptors are modular and have a capabilityof being deleted from the tuning system, modified, or replaced.
 16. Thetuning system of claim 1, further comprising a shared facility forlogging metric changes.
 17. A computer-implemented method forautomatically tuning one or more target systems, comprising the stepsof: managing at least one set of metrics corresponding to the one ormore target systems; providing one or more controllers for implementingone or more control strategies for adaptively tuning performancecharacteristics of the one or more target systems based upon the atleast one set of metrics, wherein the one or more control strategies areindependent of a particular architecture of any of the one or moretarget systems; providing one or more adaptors providing an abstractinterface to the one or more target systems with respect to the one ormore control strategies, wherein at least one of the one or moreadaptors is specific to a corresponding one of the one or more targetsystems; and automatically invoking the one or more adaptors (i) toobtain metric values from the one or more target systems to computetuning control values, and (ii) to tune the one or more target systemsusing the computed tuning control values.
 18. A computer-based tuningsystem for automatically tuning one or more target systems, comprising:a metric manager for managing at least one set of metrics correspondingto the one or more target systems; one or more controllers forimplementing one or more control strategies for adaptively tuningperformance characteristics of the one or more target systems based uponthe at least one set of metrics, wherein the one or more controlstrategies are independent of a particular architecture of any ofthe-one or more target systems; and one or more adaptors for abstractlyinterfacing with the one or more target systems with respect to the oneor more control strategies, wherein at least one of the one or moreadaptors is specific to a corresponding one of the one or more targetsystems; wherein the one or more control strategies invoke the one ormore adaptors to adaptively tune the performance characteristics of theone or more target systems to set control parameters for adjustingresource allocations of the one or more target systems.